fix(integrity): dedupe packageIds when counting resolved packages (#506)#507
Closed
ggreif wants to merge 1 commit intocaffeinelabs:mainfrom
Closed
fix(integrity): dedupe packageIds when counting resolved packages (#506)#507ggreif wants to merge 1 commit intocaffeinelabs:mainfrom
ggreif wants to merge 1 commit intocaffeinelabs:mainfrom
Conversation
`getResolvedMopsPackageIds()` produces one entry per dependency-table row, including alias rows like `base`, `base@0`, `base@0.16` all resolving to the same `base@0.16.0`. The subsequent length comparison against `Object.keys(lockFileJson.hashes).length` then fails — the hashes object is naturally deduplicated by its packageId keys, so the two counts diverge by the number of alias duplicates. Compare unique packageId counts via `Set` to match the lock file's semantics. Fixes caffeinelabs#506 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ggreif
force-pushed
the
gabor/fix-integrity-alias-count
branch
2 times, most recently
from
8f6b088 to
4be097c
Compare
Contributor
Author
|
@Kamirus this is a candidate for v2.12.2 |
Kamirus
added a commit
that referenced
this pull request
Apr 22, 2026
Fixes #506. Alternative to #507. ## What changes for users `mops install` (and any flow that runs `--lock check`) no longer fails with `Mismatched number of resolved packages: N vs M` on projects whose resolved deps include multiple aliases (e.g. `base`, `base@0`, `base@0.16`) pinned to the same `name@version`. Previously the only workaround was `--lock ignore`. ## Root cause `getResolvedMopsPackageIds` returned a list with duplicates: `resolvePackages()` keeps each alias as its own entry, then `getPackageId` collapses the alias suffix via `getDepName`, so two aliases pinning the same `name@version` produced the same id twice. `mops.lock`'s `hashes` is keyed by packageId and naturally dedup'd, so the count comparison in `checkLockFile` mismatched. ## Why this approach over #507 #507 dedupes only at the count comparison. This PR dedupes inside `getResolvedMopsPackageIds`, which (a) makes the function's contract match its name, and (b) stops sending duplicate ids to the canister's `getFileHashesByPackageIds`. Downstream membership checks (`includes`, `in`) were already dedupe-safe, so no other call site needed changes. ## Test plan Added a regression fixture pinning `core` and `core@1` to `1.0.0` plus a test asserting `mops install` exits clean and stderr doesn't contain the mismatch error. Verified that reverting the fix makes the Jest test fail with the expected error string.
Collaborator
|
fixed in #509 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #506 — the "Mismatched number of resolved packages N vs M" failure on valid projects that use aliased dependencies.
Root cause
In
cli/integrity.ts, the count comparison at the end ofcheckLockFile()uses:lockFileJson.hashesis keyed bypackageId(name@version), naturally deduplicated by the object.packageIdscomes fromresolvePackages()which retains the alias dependency-table keys (base,base@0,base@0.16) as separate entries.getPackageId()collapses them viagetDepName(), but the resulting array keeps the duplicates.So any project with aliased deps has a
packageIds.length > hashes.sizegap equal to the number of aliases, and the integrity check fails even when the lockfile is internally consistent.Fix
One-liner: dedupe via
new Set(packageIds).sizebefore comparing. Also added a comment explaining the subtlety so the next person doesn't restore the naive comparison.Repro
Covered in #506 (with attached
mops.toml/mops.lock). Short form: any project withbase = "0.16.0",x-client = "0.1.2", etc., where transitives introduce alias rows, failsmops install --lock updateat the final step.Test plan
mops install --lock updateon the Integrity check miscounts alias-tuples as distinct packages ("Mismatched number of resolved packages N vs M") #506 repro now exits 0 and produces a lockfile that subsequent--lock checkpasses.hashesentry) and confirm the check still fails with the same error.🤖 Generated with Claude Code